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ABSTRACT 


Planning and controlling the software development process 
has shown, in the past, to be an extremely diffcult task. 
The estimation of resource requirements, development costs, 
risk profiles and project feasibility has often proven to be 
inaccurate, thus costing the government time and dollars. 
However, by using obtainable management parameters, and simple 
engineering and operations research techniques, estimating 
can be done easily and accurately by taking a macro approach 
Berane estimation problem. 

This study will present the background and mathematical 
basis for a software cost estimation model. In addition, an 
example of an automated application of the model will be pre- 


Semeead and discussed. 
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tow JRODUCT ION 


A. GENERAL 

Software development within the Federal Government has 
been significantly marred by a history of projects that are 
characterized by cost and schedule overruns, and a delivered 
end-product that fails to provide the desired performance 
and function originally required. This statement is not 
mere conjecture, but has been observed and documented in the 
past. The compilation of responses to a questionnaire sent 
out by the United States General Accounting Office (GAO) to 
one hundred and sixty three software contracting firms and 
one hundred and thirteen experienced federal project 
officers has ascertained that in over 50 percent of the cases, 
92.0 percent of tne respondents experienced software develop- 
ment calender overruns, 50.4 percent of the respondents 
Pegpereeneca SOrtware cost overruns, and 43.3 percent of the 
respondents received software that required substantial in- 
nouse correction or modification prior to being effectively 
Weed. [PRer. 26: 8-10] 

fieeateredusemy in wich the Federal Government incurs 
expenditures and fiscal obligations well into the billions 
of dollars, the process of resource estimation and project 
Gentrol for software development is a major budgetary concern. 


As develooment costs steadily and rapidly escalate, this 
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concern gains added complexity (Figure 1) and some manner of 
rormal methodology which allows the project manager to 
estimate the resource requirements and to control the project 
Pe@emes necessary. 

ene requirements of such a methodology must allow for 
mieneaoaSiBity to operate with any size project yet still 
remain a function of manageable parameters such as effort 
and development time. These parameters require relationships 
to the system size (delivered source lines of code) in terms 
of such environmental factors as: 

Syeeen complexity 

use of and type of software engineering tools 

user interface 

USe Or a Target machine 

use of a development computer 

the development language used 

other human factors 

[Ref. 20: 14] 
in addition, the concept of system difficulty is a factor 
that must be taken into account, not only in terms of the 
number and types of source lines of code, but also in terms 
of the development approacn and the integration of modules 
and subprograms. 

The Department of Defense (DOD) has taken steps to 
Formalize and standardize the governing of the life-cycle of 


automated information systems (AIS). Life cycle management 


eZ 





Cost 


Percent of 


LOO 


30 


5 0 


uQ 


20 


Hardware 


fo 


id 


oO 


” 
oe 
oe 


Sortware 


Development 


Software Maintenance 


Lo 


Figure 1 


Hardware versus Software Cost 
oF 


Pee 


eed | 


ES 


Trends 


eo 





Mie, as detined by the Department of Defense, is "the 
process for administering an AIS over its whole life with 
emphasis on strengthening early decisions which shape AIS 
Bests and utility." [Ref. 6: 2] 

Among the objectives of life cycle management is to 
assure the lowest total overall cost and to provide visibility 
tor resource requirements. In order that a project manager 
might plan and control a software development project through- 
Out the entire life-cycle, he must be able to answer four 
Simple management questions in terms of cost and resources: 

is the project feasible? 

Wnat are the resource requirements? 

How long will it take? 

What are the risks? 
Unfortunately, the past has shown that these simple questions 
can prove to be extremely difficult to answer. Not only must 
these questions be answered during the initial stage of the 
project, but also throughout the entire life of the project. 


"Software development is dynamic...not static." (Ref. 20: 181] 


pe oCOPE 

This study is directed toward the role of the manager, 
his ability to address and answer the four management ques- 
tions, and the role of these questions in life-cycle control. 
Mucn of the background information 1s technical/mathematical 


in nature. These topics will be presented in such a manner 











as to allow the reader to grasp the fundamental concepts 
without unnecessary inundation by the mathematics involved. 
The emphasis will remain on the conceptual aspects and in 
the resultant numerical answers. 

The principles presented in this study are applicable 
to sortware development project managers both inside and 
Outside the federal government. Because the Department of 
Defense is one of the largest single users of computer 
technology, this study will reflect Department of Defense 


policies and techniques. 


ee AsouUMPTIONS 


it is assumed that the reader has a working understanding 


or life cycle management and the software development process. 


D. ORGANIZATION OF STUDY 

This study will be organized in such a manner as to flow 
from the conceptual to the specific. After the presentation 
of necessary background material in Chapter II, greater speci- 
P%eae10n occurs in Chapter III in dealing with the Rayleigh 
curve, its characteristics, and its relationship to the life- 
cycie. Chapter IV will deal with the characteristics and 
application of the Putnam Software Equation. Chapter V will 
present computerized applications of this methodology using 
the SLIM (Software Life Cycle Model) software estimation pack- 
age. This study relies heavily on the writings and observa- 
tions of Lawrence H. Putnam, President of Quantitative 
software Management, Inc. 
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ke OLMMARY 
Tnis study will present a means of answering the four 


basic management questions concerned with the control and 


planning of software development: 


Is the project feasible? 
What are the resource requirements? 


How long will it take? 


femme mae ics 2 


What are 
accomplished in a manner which uses the basic 


nis will be 
management parameters of time, cost, and manpower, as the 


Ba@eees FOr Dlanning and control. 
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BACKGROUND 


A. AN OVERVIEW OF LIFE-CYCLE MANAGEMENT AND THE 
Soe ne DEVELOPMENT PROCESS 


ie bee Cyele Management 
The Department of Defense subdivides the life-cycle 

of an automated information system into five broad phases: 

PMfssion Analysis/Project Initiation 

Concept Mevelopment 

Derinition/Design 

system Development 

Depioyment/Operation 


etre ra 1003.3 ) 


O> 


(Refs. 
These phases are sequential and act as a control mechanism 
for both systems development and management accountability. 

See iilcetoneAanalysis/Project Initiation 

This phase serves to identify a mission element 
neec in terms of functional requirements, validate the need, 
and recommend the exploration of alternate functional con- 
Sees tm@at Satisfy the need. Although this particular 
structure exists in large projects requiring extensive 
resource commitments, the philosophy of mission need can be 
persuasive in smaller programs and should be carried out and 
documented in a lixe manner. This phase is completed at 
Milestone 0, the approval of the Mission Element Need 


Statement (MENS). 
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Deeeoncepe Development 
The Concept Development phase serves to define 
requirements, evaluate the alternative methods that satisfy 
the need, and to recommend one or more feasible concepts for 
mueenem exploration. This phase terminates with approval 
Tor the vendor to demonstrate the alternative concepts or to 
proceed directly to the definition and design phase, given 
that one concept has been selected. Termination of this 
phase indicates Milestone I. 
e. Defrmition/Design 
The purpose of the Definition/Design phase is to 
fully define the functional requirements in terms of system/ 
subsystem specifications, and to design an operable system. 
This phase terminates at Milestone II when both the defini- 
tion and design concepts have been approved. 
d. System Development 
The System Development phase serves to develop, 
integrate, test and evaluate the system. This phase is 
completed when the appropriate functional officials grant 
approval, certifying that the system satisfies the mission 
Meeae eryeroval constitutes Milestone III. 
e. Deployment and Operation 
This phase covers the implementation of the 
approved system, the continued operation of the system, and 


all required maintenance and modification. 
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2. the Software Development Process 

There are several ways of viewing the software 
development process. For oes OP erniks  Shidy.9 ene sont — 
mere development process will consist of four phases: 

systems Definition 

runctional Design/Specification 

Development 

Operation and Maintenance 
The phases are essentially sequential, but some degree of 
Svewrap Can be permitted. in addition to the four phases, 
there 1S One step, Installation, which overlaps both the 
Development phase and the Operation and Maintenance phase 
Sremeure 2). 

a, ' oysuemer Definition 
Systems definition includes the complete defini- 
tion of the preferred alternatives or alternative, the 
establishment of bounds on manpower effort and development 
time, and the refinement of costs. 
De Glmectema! Design/Speciafication 
This pnase involves the preparation of detailed 

system specifications for both the application and technical 
software support, and the finalization of technical proce- 
Gures and programming policies. Finally, detailed system 
specifications are converted into detailed programming 


specifications. 
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c. Development 
The Development phase can be further subdivided 
MatG two steps: 
Design and Coding 
Test and Validation 
Meeo- tWO steps include the coding of applications specifica- 
meeonseand tHe conducting of unit and string testing of the 
Machine executable instructions. In addition, program docu- 
mentation is completed. System testing requirements are 
prepared and the test is carried out. 
d. Operation and Maintenance 
The final phase, Operation and Maintenance, 
includes system refinement, tuning, post-implementation 
reviews, and the continued operation and required 
Maintenance. 
e. Installation 
The installation of the system overlaps the end 
of the Development phase and the beginning of the Operation 
and Maintenance phase. This step includes implementation and 
conversion planning as well as the actual conversion and 


phased implementation. [Ref. 2: 14-18] 


eee meen VERSUS MACRO METHODOLOGY 
The traditional approach to size/time/cost estimation 
has been the use of a micro-methodology. (Table 1) This 


MemiecOlocy 1s largely intuitive and begins by fixing the 


a 





nO. 
a. 


2. 


ie 


atipaes al 
Traditional Methods of Cost Estimation 
Mees. 12279-2331, 11: 24, 27: 12-13, 29: 618-619] 
Experience Method 
Constraint Method 
Top-Down Estimating 
Similarities and Differences Estimating 
Analogy Method 
Seancards Estimating 
hoeto Estimating 
Eeteom-Up Estimating 
Units of Work Method 
Smoothing and Extrapolation Estimating 
Number of Instructions 
Quantitative Method 
Bost fer instruction 


Percent of dardware Method 


oe 





Size, start date and duration of each distinguishable 
activity. Adjustments are estimated and applied based on 
the caliber of personnel, complexity, and so forth. Finally, 
activities are arranged using network models such as PERT 
(Program Evaluation and Review Technique) and CPM (Critical 
fewer Method). LRef. 11: 23] To even further quantify the 
development process, the number of modules within the entire 
process, the number of statements per module, and the cost 
Bee Statement are estimated. [Ref. 20: 13] Productivity is 
the critical input to this methodology. The major drawback 
1s, however, that productivity varies greatly between 
organizations and individuals. 

The micro approach can work well on small projects where 
there is little detail involved and few programmers are 
required. Troubles develop when the program being developed 
involves large volumes of detailed specifications and hundreds 
of thousands of lines of source code. 

When uSing traditional methodologies, most errors in cost 
estimation are a result of underestimating size, sometimes by 
as much as a factor of three. This is usually the result of 
erroneously relating productivity to delivered source lines 
meeode. in addition, it is common to find a productivity 
factor that has a standard deviation two and one half times 
greater than the expected value. [Ref. 7: 2] More discussion 
concerning productivity will be accomplished later in this 


GMapter as well as in Chapter IV. 
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The macro approach views the project from a higher level. 
Beginning as early as the Systems Definition phase, manage- 
ment Darameters serve as inputs to the methodology. The 
inputs can be used to generate the expected life-cycle curve 
of manpower versus time. As the project progresses and the 
perameters become firmly established, the life-cycle curve 
can be updated. Milestones can be located along the curve 
and parallel tolerance curves can be generated to indicate 
the percentage of uncertainty. Through the information 
presented along the life-cycle curve, control can be exer- 
Cised over the life-cycle of the project. The key to this 
approach is that the curve can be shown in terms of manage- 
ment parameters: manpower, time, and effort. [Refs. 11: 24, 


20: 130] This is the approach that will be presented in 


mars Study. 


ee COLTWARE MYTHS 

Most large-scale software development projects that go 
astray do so because of calender overruns. [Refs. 5: 14, 
26: 9] Much of the problem with overruns can be traced to 
myths that surround software engineering: 

Development effort is the product of people and time. 


Programmer productivity (source statements per unit of 
work) is constant and can be set by management. 


Productivity varies directly with the effort applied. 
Men and months (time) are interchangeable. 


[Refs. 5: 14, 16: 352, 17: 348, 20: 14] 
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Wemevevelooment Fffort 

The assumption that development effort scales 
linearly as the product of people and time (Figure 3) leads 
One to believe that time can be arbitrarily set by manage- 
ment and that the requisite number of people can be assigned 
Bevechieve the desired results. As will be shown in the 
fOlleGwing chapter, this reasoning can lead to both calender 
ana cost overruns. 

me regdueti v1 Ly 
Traditionally, management estimates the number of 


source lines of code and applies a historical overall pro- 


ductivity rate to determine a man-year number. For example: 
Given: 
Bevree Lines of Code (Ss) = 200,000 lines of code 


(estimate) 


Productivity (PR) : Total Source Lines of Code 


Cimeswee ane I.) 


1000 Ss/MY (man-years ) 


therefore: 
ses Sez OR cUCmes 
Pevelopment sfrort (CE) = TaOnSar uy ZOO a ine 


Lawrence Putnam, during the course of his studies, 
performed a least squares best fit, uSing data taken from 
over four hundred projects of the United States Air Force's 
Rome Air Development Center, against delivered source lines 


of code for each of the four hundred projects. The data 


a 








Manpower 
10 







20 Years x 10 Men = 200 Man-Years 





ZOO MAY 


Cn 


0 
20 Time (years) 
Manpower 
ug 
5 Years X 40 Men = 
29 ZO Cee 200 Man-Years 
a 2 3 4 5 


Time(years) 


Paeure. 3 


The Development Effort Myth 
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expressed a wide range in system size (100 to 1,000,000+ 
source lines of code), project duration (one month to 6 
yearst+), man-months of effort (one MM to 20,000 MM), average 
number of people (one to several hundred), and productivity 
(19 Ss/MM to several thousand Ss/MM). The resulting corre- 
Hieron COetricient after performing a least squares best fit 
tO Droductivity (Ss/E) versus delivered lines of source code 
Meweeound tO be r = .033415, thus displaying virtually no 
Memeelation. LRefs. 20: 29-30, 24: 87] 

However, after performing further least squares best 
eee eete tions, broject duration in months versus delivered 
Semece lines of code showed r = .700256. When total man- 


months versus delivered source lines of code were predicted 


linearly, r was shown to equal .853915. When a least squares 


rt 


best fit was performed for the average number of people 
involved in the development effort versus delivered scurce 
lines of code, the correlation coefficient showed r = .80388. 
PRefs. 29: 29-30, 24: 88-90] Although standard deviations 
proved to be large, three of the variables did show good 
correlation to delivered source lines of code. Furthermore, 
it was shown that there is virtually no correlation between 
productivity and delivered source lines of code (Table 2). 
Geet vaiston dnd €.Pr. Felix, in their study, began a 


software measurement project for the IBM (International 


Business Machines Corporation) Federal Systems Division in 
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Table 2 
Correlation Coefficients (r) 


(Based on Least Squares Best Fit against Delivered Source 
Pames of Code GDSLOC)) 


Correlation 
GseGniclent 2) 


Broqguetivity O03 34> 
eo5/75) 

Project Duration O27 C0255 
Time 


Moca! Errort 
(MM or MY) Genco c obs 


Ave. Number of People 
Involved in Development OC uiscc 


eerort 


28 





19/2. They found twenty-nine variables that had an 


(D 


meecmely high correlation with productivity. [Ref. 28: 62] 


M4 


Bewtieures concerning these variables are tabulated in 
Appendix A. 


Pe eee neerechamecability of Men and Months 


One o 


Kt, 


the largest problems associated with software 
emegineering evolves from the erroneous utilization of the 
Semecpt OL the man=month. Because cost varies with the 
Beeaucct Of men and the number of months (time), using man- 
Meme 4245 a Means Of measuring the size of a job implies that 
men and months are interchangeable. Unfortunately, they are 
not. Man-month is a measure of effort. "The number of 
months of a project depends upon its sequential constraints. 
The maximum number of men depends upon the number of inde- 
pendent subtasks." [Ref. 5: 25-26] 

If an appropriate development schedule is established 
at she outset of a project, satisfactory work can be accom- 
plisned within the allotted time by the assigned programmers. 
fRef. 11: 23] Otherwise, the oft quoted Brooks' Law takes 
over: "Adding manpower to a late software project makes it 


Meer.’ [Ref. 5: 25] 


mw. SUMMARY 
Lite-cycle management and the software development process 
OoIfer a structured means for planning, developing and 


Semenolline the software project. Traditionally, the resource 


Za 





estimation process has been a micro approach. This is an 


intuitive approach which hinges extensively on the relation- 


Ship between productivity and delivered source lines of code. 


t t) 


Daca rom Dast projects indicates that no correlation exists 
between the two. Another erroneous assumption made in the 


software engineering field is the use of man-month as a mea- 


UV) 
eS 


re oi the size of a project. Man-month is a measure of 


frort. Another estimating approach, macro-estimating, makes 


(D 


use of accessable management parameters: time, manpower, and 
cost. in order to accurately estimate the project resource 
requirements, the various software myths that manifest them- 
selves in the more traditional approaches have to be 


@eomassed. 
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fit. THE LIFE-CYCLE MANPOWER CURVE 


Be previously shown, the software development process 
can be subdivided into sequential and overlapping phases. 
These phases can also be further subdivided into steps. The 
relationship between the phases within the system development 
process is such that required work for a particular phase 
Cannot begin until specific work in an earlier phase is com- 
pleted. The pnases display technological interdependence. 
PRef. 13: 156] 

the software development process also displays the 
traits of a homogeneous project. The development process is 
Buch cnat each phase has at least one technological inter- 
dependence tie to another phase. Otherwise, each phase 


could be considered an independent process. [Ref. 13: 156] 


mee CeeRACTERISTICS OF THE RAYLEIGH MODEL 

in the life-cycle model developed by Peter V. Norden 
during a course of study he conducted between 1956 and 1964 
at the IBM Development Laboratories in Poughkeepsie, New 
York [Ref. 12: 219], a small number of successive phases of 
work, with each phase being based upon the manner in which 
complex technological problems are approached, are mathe- 
matically fitted to a life-cycle curve. This life-cycle 


curve can be mathematically represented by the Rayleigh 


oe 





equation, a mathematical form from the Weibull family of 


reliability functions. The equation that describes each 
phase is: 
Z 
i = 2Kate 72° (Figure 4) 
where 
y' = the manpower utilized during each time period 


(man-years/year or man-months/month) or the 
number of people involved in the activity at any 
given instant in time. 

XK = the total cumulative manpower (life-cycle effort) 
utilized upon completion of the project (man-years 
or man-months). 

a = the shape parameter. This governs the time 
required to reach peak manpower. 

t = the elapsed time, in years or months, from the 
Seart Of theseycle: 


[Ref. 13: 156-157] 


The Rayleigh curve appears to retain its validity only 
for an activity which requires the making of large decisions. 
A combination of phases will not result ina single overall 
Rayleigh curve. [Ref. 14: 13] This principle states that 
the summation or a series of overlapping Rayleigh curves will 
not produce another Rayleigh curve. There is, however, a 


Significant observation that is termed the Software Development 
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‘Single Cycle' Phenomenon that ignores this additive Prine ap ex 
the pnenomenon is such that the process of software develop- 
meme yields cycles that do add up to a Weibull shape. This 
seems to imply that the software development process is a 
homogeneous problem solving effort, even though the effort is 
broken down into phases. [Ref. 12: 225] This phenomenon was 
first noticed by Lawrence Putnam, then with the U.S. Army 
Computer Systems Command. Its validity has since been corro- 
meeetcd by Many Other studies (Table 3). Further mention of 
ene Rayleigh equation/curve will be in the context of software 
development. 

Multiplying the Rayleigh equation by the labor rate con- 
Meets 2t to a cost function. Integrating the equation over 
time (rigure 5) produces cumulative effort and cost of any 
meme, LRefs. 13: 158, 29: 5] 


Z 
eee) =e ON 


and taking the derivitive of the Rayleigh equation (Figure 6) 
Z 
ieee” (lo 2at‘) 


Puelas the Ghange in the total effort at any time. [Ref. 13:158] 
The Rayleigh equation is expressed in terms of management 
parameters, in this case, time and effort, which are necessary 


or a macro-metnodology. These management parameters can be 


b4) 


further expressed in terms of manloading and cash flow rates, 
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Table 3 


A Sampling of Those Who Have 
round Evidence of Rayleigh-Like Behavior 


Peer. 


Peveseizator 


puUmermy Computer Systems 
Command (CSC) Systems 


° 


Apolilo-Gemini 


NSA System 


Pee rOnics Systems Division 
@eoD), USAF 


Defense Log Mgt Agency 


Apolio-Draper Labs 


Porm e@al. Edison 


General Electric Factory 
Corerol (MICS) 


Wolvyerton's Data 


uvoel Aron and IBM Yorktown 


Riordan's Dynamic Model 


20: 32-33] 


ADD Lecatlom 


Biveimeces 


Very Large Real-Time 
Maxed X10-1010 My) 


Imbedded ee Wpns Sys) 


Business (Logistics) 
Mixed 

Real-Time Telecomm 
On Board Software 


Small On-Line Customer 
Information System 


Medium-Size Process 
VoOMmEmol system 
Large Aerospace and os 


Large System Software 
and Application 


General Systems 
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and cumulative effort and cost. In addition, DEO yect 
delivery schedules, in terms of project milestones, can be 
empirically located on the curve. 

Iz nas been determined that the shape parameter, ‘a’, 


1s related to software development time such that 


7 
7 
9 +? 


ea gaevyel@pment time 


Mathematically, TG is the time that the Rayleigh curve 
@-aenes a2 maximum. It has been empirically demonstrated 
that this is essentially the time that a system becomes 
Operational, the development time. [Refs. 17: 352-A, 20: 17] 
For purposes of this study, it will be assumed that ta equals 
the development time for a system. 

The relationship between development time, tas and the 
Rayleigh equation, and cumulative manpower, K, and the 
Rayleigh equation are graphically demonstrated in Figure 7 
and Figure 8. 

Meets also interesting to note that, in Figure 5, thirty- 
nine percent of the total effort utilized takes place during 
the first quarter of the phase. Seventy-eight percent of 
mee tora! esfort utilized occurs during the first 43.5 percent 


of the phase. These figures point out the realistic time and 
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manbower requirements after development time for such factors 
as Maintenance, modifications, and continued program 


management. 


PRECT OF SYSTEM NOISE AND RANDOM BEHAVIOR 


UJ 
tq 


One hundred and seventy-four time history data points 
of thirty eight different systems, taken primarily from the 
U.S. Army Computer Systems Command, National Security Agency, 
and IBM - NASA, were normalized, in order to make the ranges 
comperable, and plotted. Lawrence Putnam fitted the best 
Rayleigh curve to the data, along with a ninety percent 
confidence interval, with the resulting coefficient of 
determination, . equal to .7744 (Figure 9). 

It 1S quite evident that there is considerable scatter 
in the data. One must consider that the process is subject 
to the laws of probability; due to less than perfect manage- 
ment, crises will appear and the size and solution become 
the probabilistic factor. In addition, it can be reasonably 
assumed that management did not respond to project require- 
ments. Also, data is not necessarily recorded in a careful, 
precise manner. [Refs. 20: 19, 24: 74] 

What allows the Rayleigh equation to be such a powerful 
management tool is that, even with considerable scatter, 
development time can be determined with an uncertainty less 


than three percent and that total effort can be determined 


41 











[SZ the “FeN] 6 SanstTy 
VVAWLL GS3ZIIVWHON 


O'e Gi¢ O'e St O'L c 0 


€) 





%26°8 = y1/> 


boll =_y 


n 


/A 
b° 
TAGOW HOIA TA VY/NAGUON 

OL 


VIVO AYVMLAOS AO Lld GAZITVWHON 


HSMOCNVIN 
CAZIIVYIHON 


42 








with less than nine percent uncertainty. It is now obvious 


E e “ho : 
PieeecesDlte Nolse in the system, Hea s Sent e parame Lens Can 
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n@ ratio k/t demonstrates a significant relationship 
to the Rayleigh equation. The variable dimensions of this 
Patio reflect force, the time rate of change of momentum. 
Meee oS. 300, 22: 19) By linearizing the Rayleigh equation 
through the process of logarithms 


(-Log e)t? 


Z 
2ta 


Log(y'/t) = Log(X/t 4°) + 


and plotting the equation in terms of manpower applied to a 
system over time squared, with Log(K/t ,°) being the inter- 
cept and 1/(2 eee the slope, a straight line is produced. 
Putnam performed this operation for some one hundred systems 
and round that the argument of the intercept, ne reflec- 
ted system difficulty. Those systems considered easy to 
develcp had low intercept values and, conversely, those 
Pemseitdered more difficult to develop had high intercept 
values (Figure 10). In terms of the management parameters, 
Me is evident that cumulative manpower 1s directly propor- 
tional to system difficulty while deveiopment time is 
Mrversely proportional to system difficulty. In other words, 
eeemeditficulty reflects programming effort and the time 
mequired to produce the svstem. (Ref. 16: 350, 20: 35-36, 


we: 20 | 
ie 
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Linear Form of the Rayleigh Equation 
fe Sneemelo: 35020: 365% 22 8227 | 
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D Jey - ‘ . . e 
~roressor George J. Fix, of Carnegie-Mellon ee eins I Ly. 
snows that the dependence of the system difficulty, D, is 


euen that D is a function of time, cumulative manpower, and 


On-hand manpower. 
te Dt. ,y,y') 


Pfiis implies that difficulty increases with the number of 
Beeer>e involved in the activity, both on-hand and cumulative, 
Became. (Ref. 8: 363] 
1. feasible Region 

One can visualize a feasible software region based on 
cGevelopment time and life-cycle man years (Figure 11). A 
system can span from a life-cycle man-year of one to almost 
any given total number of life-cycle man-years. The develop- 
ment time can range from one month to ten years or more. 
For large systems, though, bounds must be established, there- 
by creating a development-feasible region. Development time 
can be limited from two to five years: five years being an 
economic upper bound, two years reflecting the lower limit 
due to limitations on manpower buildup. [Ref. 16: 351, 
Mee 37, 24: 115] 

Frederick Breoks alludes to this mover bound by citing 
V.A. Vyssotsky's estimates that "a large project can sustain 


a manpower buildup of 30 percent per year." [Ref. 5: 179] 


Norden's equation 


2 
yi = 2Kate ct 
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holds to this principle when the development time is equal 
to or greater than two years. [Ref. 22: 23] The manpower 
buildup invokes Brooks! intercommunication law for those 
projects where the parts must be separately coordinated with 
the other parts. This law states that effort increases as a 
function of n(n-1)/2. By adhering to this law, "three 
workers require three times as much pairwise intercommunica- 
]i1On a5 two; four require six times as much as two." 

[Re=. 5: 18] Lawrence Putnam rationalizes this lower limit 
Pven more plainly. He says that large software projects 
bess than two years in duration cannot be managed "without 
ferotc measures." [Refs. 16: 351, 22: 24] 

By portraying the feasible region in three dimensions 
through the process of adding a new axis reflecting system 
Birr leulty , ena a difficulty surface is created (Figure 
my. &£t should be noted that just as in Figure 10, as 
development time is decreased, difficulty increases. 

Qe tenmry Gradient 

Systems tend to fall on lines which correspond to a 

constant degree of difficulty on the difficulty surface. 


This constant difficulty can be expressed as 


K/t.? 


tz ~ [VDI. 


This difficulty gradient reflects the organizational capa- 


Dility while doing that type of work for which the constant 
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was derived. [Myers: Ref. 30] As system size increases, 
development time also increases in order to maintain a 
Sescait Magnitude of VD. [Ref. 15: 352] 

Putnam found, through studying all the systems of 
the U.S. Army's Computer Systems Command, that if a system 
is entirely new, designed and coded from scratch and con- 
means Many interfaces with other systems, |VD| = 7.3. If 
a system is a new stand-alone system, |VD| = 14.7. If the 
system is rebuilt from existing systems where large segments 
Boelogic and code exist, |VD! = 26.9. Other data from IBM 
and the Rome Air Development Center has shown that for what 
Seenam Calls a Composite I system, one which consists of 
independent subsystems which reflect few interactions and 
interfaces, as well as subsystem development occurring with 
Sensiderable overlap, |VD| = 55.0. For a Composite II 
System, which is similar to a Composite I but with minimal 
vice few interactions and interfaces, and with subsystem 
development occurring essentially in parallel, |VD| = 89.0. 
Putnam does note that as more data becomes available for 


different classes of systems, more constants are likely to 


Mmemeoee. | Refs. 15: 352, 22: 3, 24: 154] 
The values of the difficulty gradient for a particu- 
lar type of system will vary between software houses. This 


varlance is based on the average skill level of the software 
nouse's analysts, programmers, and management. For a 


particular kind of work, the values of the difficulty gradient 
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bexfiy 


reflect a learning curve for the software house. Peer. 15. 
352] Because of the skill variance and learning attributes, 
one can expect an uncertainty of fifteen percent for the 


Dase gradient values expressed in the previous paragraph. 


Ref. 24: 154] 


Pee eeet TERNS OF MANLOADING 

There is a myriad of possible manloading patterns. For 
example, they can be rectangular, trapezoidal, triangular, 
Or just about any geometric shape one can think of. Unfor- 
tunately, the perceptual manpower needs of the project may 
not reflect accurately the real needs. "If management 
responds promptly to the perceived needs of the ongoing 
project, the manpower loading pattern will resemble one of 
the large number of Rayleigh-Norden curves possible." 
mer. 20: 25] 

For the example as portrayed in Figure 13, the rectan- 
gular manloading pattern, perhaps the simplist for the 
manager to implement, is shown plotted against a Rayleigh 
pattern. 38y applying the concept of the homogeneity of 
systems development, additional personnel cannot be judi- 
Cliously applied to the project until the initial work is 
completed. The rectangular approach results in initial 
wasted effort, a lack of effort when critically needed, and 
extra effort toward the end of the project. Because of the 


ieeeeor Cifort during the critical periods, schedule 
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slippage results and further additional effort is required 
at the end of the project. This additional effort continues 
at the maximum manpower level, thus compelling the project 
to continually impose a maximum cash flow rate and probably 
Bemeing 4 cOSt overrun. If Brooks' Law is adhered to, this 
additional manpower will not keep the project on schedule. 
Correctly applying manpower involves projecting an 
expected Rayleigh-Norden curve and setting control limits, 
based on the uncertainty of the initial data. As more 
information concerning manpower becomes available, the curve 
is adjusted to fit reality. The project manager is afforded 
the luxury of being able to project manpower needs, update 


mes meeds, and control the effort. 


fe De@exnM@yATION OF MAJOR MILESTONES 


1 


Major milestones are located empirically along the 
Rayleigh curve based upon the coupling of life-cycle sub- 
cycles to the overall curve. [Ref. 20: 117] Table 4 shows 
the milestones derived by Putnam from data from the U.S. 
Army Computer Systems Command. The figures in Table 4 
display quite a range; however, given this range, should a 
project exceed the maximum time for a particular milestone, 
1t should be quite evident to the project manager that there 
iS a problem with the project that requires attention. The 
project's not meeting the minimum time should be a signal to 


the project manager that either he has an exceptional team, 
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Table 4 


Times of Major Milestones 
| Piet s eee, fie CLO | 





Event ioe 
Peeeen Cerctirtication 
Post 2235 
Expected On 4s3 
Last Oe orns 
a . 
Systems Integration Test 
Peers c Uo 
Expected Deo od 
Last Oe 7 oe 
Prototype Evaluation Test 
ee SC Went: 
Expected Q.800 
Last O77 30 
Start Installation/Extension 
Fame Oecwe 
Expected O22 0 
Last Le 2o0 


MOTE: Sfmere is a .90 probability that t/t, will lie 
between first and last for a particttlar milestone. 
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his planning was not accurate, or something was accomplished 
ln a cursory manner. It has been shown through data from 
several hundred systems, reflecting various development 
Prrytronments, that the relative occurrence of the four 
milestones is very stable, with respect to the expected 
Value, im most organiZations and environments. [Ref. 21: 140] 
It is important to remember that both the development 
time and the milestones are the most sensitive elements in 
the system development process. Milestones scale ina 
linear fashion; thus, if one is late meeting a milestone, he 
should expect to be late on succeeding milestones. Once 
behind, the project manager is not afforded the luxury of 
being able to catch up; “adding manpower to a late software 
project makes it later." [Ref. 5: 25] Realistic milestones 
Mmse be set at the beginning of the project. [Ref. 20: 71] 
Determining the major milestones not only aids the project 
Manager by functioning as a planning tool, but also is a 


means for measuring actual accomplishment. [Ref. 21: 1406] 


Meo oe SLZE VERSUS THE LIFE-CYCLE CURVE 
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The relationship between development effort and life 


epee vet fort 
zm = .4K 
holds true for large systems, those systems with more than 


75,000 source lines of code. This relationship increases in 


a non-linear fashion as system size decreases. 
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For small systems, those with less than 18,000 source 
tines of code, the life-cycle curve closely approximates the 
maeve tor the Design and Coding phase (Figure 14). Because 
there 15 very little system overhead, the development time, 
Ta Mom@ear the ena Of the curve. In small systems, the 


WiFe cycle curve reaches a peak at 
t4/ v6 beet. 29: 76] 
The equation for the curve is 
2 
eo / 


Z 
= ee s (Ret. 2i25175 ] 





In the range of 18,000 to 75,000 source lines of code, 
che overhead support activities (documentation, integration, 
testing, maintenance, and management activities) rapidly 
increase. Throughout the range of this transition zone, the 
life-cycle curve expands from approximating the design and 
Pee ne Gurve to the full life-cycle curve. 

This range of system size requires an additional para- 
meter in the solution process which makes the solution 
extremely complicated. The solution involves complex 
engineering mathematics and is well beyond the scope and 
intent of this study; however, the solution has been auto- 
femeed ama is included in the SLIM (Software Life Cycle 


‘lodel) software estimation program. SLIM and its 


sunctions will be discussed in Chapter V. 
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Figure 14 


The Life Cycle Curve versus System Size 
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G. SUMMARY 


niemeunve resulting from the Rayleigh equation 


2) Z 
a -¢t 2ta 





can be used to represent the life-cycle of a software project. 


Even though system noise and random behavior can be expected, 


ime and manpower can be estimated with uncertainties less 


ct 


han three percent and nine percent respectively. lLinearizing 


ct 


the Rayleigh equation results in the ability to determine 
System difficulty. The creation of a three dimensional project 
feeieibt lity area offers the ability to visualize a difficulty 
gradient reflecting organizational capability for a particu- 
lar type of work. Based on empirical data, project mile- 
Geones Cam be located along the Rayleigh curve which can, in 


turn, be valuable as a measure of project control. 
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Pee Slee ECONOMICS: ~THE SOFTWARE EQUATION 


in the previous chapter, equations, relationships, and 
variables were introduced that allow the project manager to 
Dlan and control the sortware development process. Two key 
variables, life-cycle effort, K, and development time, ta: 
afford the project manager the ability to generate both the 
instantaneous and cumulative manpower requirements, as well 
as the development costs, through the application of the 
Rayleigh equation. 


This chapter serves to show the relationship of K and 


ty tO the software development process. This relationship 
is expressed ina very powerful management tool: the 
software equation. In addition, the answer to the fourth 


management question 
What are the risks? 


will be addressed through the development of risk profiles. 


A. THE SOFTWARE EQUATION 

The software equation, a mathematical relationship 
developed by Lawrence Putnam, is an extremely powerful tool 
for planning and evaluating the development effort of the 
software life-cycle (Figure 15). The software equation is 


expressed as: 
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wnere 


Ss = expected number of source lines of code. 
Ck = technology constant. 

t, = development time (years). 

K = life-cycle effort (man-years). 


The mathematical development of the software equation will 
not be covered in this study: however, an explanation can 
Bemiteund in rezerence 9: page 828, reference 15: page 353, 
reference 17: page 352-B and reference 18: page 108. 

By rearranging the software equation and applying a 
Factor of .4 to reflect the development effort being 
Pemmertaately the first forty percent of the life cycle 


curve, the development effort can be determined: 


concn 1 
C — 


eek = .4(— 
Net J t 


T] 


By applying the burdened labor rate, the equation can be 


Memeertec to a cost function: 


Development Cost = ($/M-Y) .4 (38 : aa 


tq 


Meese 29: 304, 20: 7] 
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Technology Constant 


-? 
° 


The most difficult variable in the software equation 


ot 
O 


04 


rasD 1s the technology constant. The technology constant 


mene state of technology being applied to the software 
development; the environment in which the development 


. or 


takes place; the development equipment available, which 
in turn affects program turnaround and the time needed 
ror debugging and testing; the extent to which modern 
programming practices are incorporated into the develop- 
ment project." [LRef. 20: 40] 

The technology constant for a firm can be calculated 
Ziven the delivered source lines of code, development effort, 
and development schedule of completed projects. For a new 
project, values calculated from other projects completed by 
the particular software developer can be compared against 
that which is estimated for the new project to determine if 
the new constant is reasonable. It is important to remember 
that a technology constant derived for a particular software 
house is not necessarily indicative of the technology con- 
meett fOr another soitware house. 

John £. Gaffney, of IBM-Manassas, using data from 
Sortware development projects performed at IBM, Manassas, 
MeGa@aia, cOUnd a correlation coefficient, r, of -0.72 
between the technology constant (Gaffney refers to the tech- 
nology constant as the development constant) and code com- 


plexity. In his study, code complexity is based on the 


Proportion of conditional jumps in the code. This infers 
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that 391.3 percent of any variation in the technology con- 
stant, Ck, can be explained by the measure of code com- 
piexity. (Ref. 9: 830] 

2. Trade-off Law 


The equation for development effort 


Ss 


eye aes 


CK u 


iv] 
it 
f= 

cm 


menleects the power ot the software equation: the trade-off 
law. 
By improving the development environment, CK increases, 

thus decreasing the development effort required to complete 

a project. By taking out the "whistles and bells" from the 
System and reducing the number of source statements to, for 
example, .95 Ss, cost will be reduced to eighty-six percent 

of the original cost. [Ref. 20: 7] Given a specific environ- 


ment with source lines of code and technology held constant, 


Constant 


. - 
d 


= = 


effort decreases as the inverse of development time to the 


fourth power. With a small change in time, a quantum change 
in effort results (Figure i6). “in software development, 
time is money. By giving a little (time), we can save a lot 


Sormmemey)." |Ref. 20: 43] 
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Tr one is able to increase his technology constant 
through, for exampie, the purchase of a development computer 


ea ciaes increase is such that 
@eenew) = 1.3 Cklold) 


the manpower savings can pay for the development computer. 





Since 
Development Cost(new) = os Development Cost(old 
eS 
= 45.5% Development Cost(old) 
A 54.5 percent savings (100.0 percent - 45.5 percent) on an 


eld development cost of $1 Million would equal $545,000. 
This savings would certainly be enough to buy a powerful 
development computer. [Ref. 19: 804-805] 

By invoking the tradeoff law, the project manager can 
ertfect substantial savings by improving his development 
environment, keeping the system size as small as practical, 
and by scheduling as much time as reasonably allowable for 


the development effort. [Ref. 19: 804] 


Pee olarik THE PROJECT 

in order to initiate development planning and control, 
the system size must be determined early in the system 
definition phase (point 1, Figure 15). Because the actual 


design functions have yet to be initiated, the project 
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manager has access only to broad estimates of the system 
mzes yet, this is enough to allow him to determine the 
Basic economic feasibility of the project. There will be a 
Meemendous degree of uncertainty in the early sizing, but 
this 1s to be expected. To demand pinpoint accuracy during 
eeeem Gefinition is an effort in futility. 

As the system definition and functional design/ 
specification phases progress, more is known about the 
system and estimates of system size become more accurate 
momenes 2 and 3, figure 15). By the time that detailed 
design begins, uncertainty can be reduced to within the 
limits of engineering accuracy. [Ref. 21: 191] 

i ween! Sizins Technique 
Sizing Will be performed using PERT (Program Evalua- 


tion and Review) sizing techniques. Expected system size is 


determined by: 


aut 4m +55 


Expected Ss = z 


where 
a = smallest possible system size 
m = most likely system size 
b = largest possible system size. 


This equation is an estimation of the expected value of a 
Meese Dutlon and skews the value toward the most 


maeertain side. 
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For the first sizing attempt, during the system defi- 


Mees On please, such a wide range of uncertainty exists that 


fs 


Simple average will suffice such that 


a D 


= i 
eeeeeetedad Ss = aT 


fhe standard deviation is determined by the standard 


Bevead sion OF the Beta distribution of system sizes: 


me DUS 4 


O) 


This 1s the range in which 99 percent of the values are 
expected to occur divided by six. Therefore, the system 


Size will ecual 


Pee -eexpected Ss + OSs. 


Statistically, there is a fifty percent chance that the 
system size will fall on either side of the expected system 
Size. There will be a sixty-eight percent certainty of the 
system being within one standard deviation of the expected 
system size, ninety-five percent certainty that the system 
Size wlll be within two standard deviations, and 99 percent 
certainty that the system size will be within three standard 
deviations. 

The sizing process is demonstrated in the following 


example. 
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g¢ Example 


IND 
ny 
id 
8, 
4 
UY 
f+. 
IN 

fe 
| 


Herly in the system definition phase, the project 


manager is given the following estimates of system size: 


Baie LON a m 

module L 76000 30000 
Module 2 87000 112000 
Meaule 3 69000 99000 


Meee the PERT sizing technique, the 


5 
117000 
136000 


Zep 


following expected 





values and standard deviations are computed: 
Buin tOn Expected Ss oSs 
Meduie 1 Sao Be3g8 
Module 2 Tigers 3 Siiow 
Medule 3 clolew| Loe 
system sU0sT67 17 8 cb 


Expected Ss(total) is the summation 


Been module. oSs(total)is equal to 


y E(oSs)- 


On Enew ee peered SS of 


The results indicate that there is a sixty eight 


percent certainty that the system size will be 


sOere5/ + 12836 source lines of code 


6 





The numbers are rough estimates and the variance is 
extremely large; however, the project manager now has 
reasonable figures within which he can plan. 


"Ww 
aa 


}4- 


Dur the Functional design phase, the project 


Ug 


manager receives more detailed estimates based on further 


modularization of the system. 


BuReTLoONn a m Db 
Module 1A 320-75 3 7 ieee 43900 
Module 13 29550 32429 38475 
Module 1C 18225 Sa 2 40900 
Module 2A Wve? S 33450 61248 
Module 28 39950 47120 bos 
Module 3A 27200 39805 43715 
Module 3B 24900 Si Lowers 2507S 
Meadmle 3C 23875 29375 34345 
meet Sizing computations reveal: 

Bome c1LON Expected Ss oss 
Module 1A 37446 oe 
Module 13 S72! 1488 
Mo@dule LC sew 3779 
Module 2A Bae aizeg 
Module 23 47297 Zou! 
Module 3A 2638 HAAS AL 
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Module 3B Sk SG dons 


Module 3C 29287 1745 
System 300291 7162 


Although the level of detail is still not very great, 
an even more refined expected number of source statements is 
now available. What is even more important is that by 
BeUrther modularizing the system, the standard deviation is 
substantially decreased; in this example, the uncertainty is 


reduced by more than forty-four percent. 


fe SeeeLOPMENT TIME/EFFORT DETERMINATION 
Far too often, the development time for a project is 
arbitrarily established by management. Because the develop- 


ment process 1S so time sensitive, 


Constant 
u 


d 


Ra 
iG 
setting development time based on factors external to the 
project can lead to unanticipated and unwanted difficulties. 
For example, the software project in the previous section, 
mamerder fOr it to be ready for a business symposium, has a 
two year development time eee upon it. The system is 


a new stand-alone system with the following parameters: 


Cx = 10946 
Ss = 300,000 
oss = 5985 


S/MY = $50,000 
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Beers use Of che software equation, it is calculated 
inet 

F = 514.68 man-years 

Devclopment Cost (SE) = $25,734,009 
Mees resulting effort and cost is ludicrous. 

By plotting the software equation and difficulty gradient 
as development time versus system size, given a technology 
constant of 10946 and |VD| = 14.7, a tradeoff region is 
developed (Figure 17). With the difficulty gradient imposing 
= Min@mum constraint, it is obvious that the system cannot 
be developed in two years. 

By uSing the tradeoff region or substituting the diffi- 


culty gradient 


K = |VD| > 


mmeO une software equation, 


Ses! 1/7 
(ar) 


ta on TID ) 


the earliest possible time that the development can be com- 
pleted is 2.815 years or 33.8 months, almost ten months 
longer than the time that management arbitrarily set. The 
Byscem ditficulty precludes a development time less than 
33.8 months. However, the project can be accomplished such 


menatt: 
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SUT], PUP JAOJFTY Seztg usemieg Jyoepeuy, 


[Te oots ae 
(90 1S0) 3JZ1S WSLSLS 


0° O00000h 0  OOOO0SE 0“ OO000E Se cOoCOSe¢ 0°00000¢ 
oar 





MN 


= Oe) = 


JWIL LNIWdd 1SA50 


(Sdbsh) 


ven 





ta = Jo. = Monts 
[ee - 327.03 man-years 
B = 131.15 man-years 
p= 90,557,723 


By ineweasing the development time by almost ten months, a 
Beomeercent reduction in erfort and development cost is 
acnieved. 

By further increasing development time to three years, 


more can be saved in terms of effort and development cost: 


tx 
i 


254.18 man-years 


ty 
i 


101.67 man-years 


SE Poss 201 


oF 
ut 


The application of the software equation and the trade- 
orf law provides a powerful basis for a usable software 
economics relationship. This will allow the project manager 
to realistically establish time and resource requirements 


with respect to his development environment. 


D. LINEAR PROGRAMMING SOLUTION 

Because more than one unknown is being dealt with and 
management constraints can be applied to the development 
process, an Optimal solution, either in terms of minimum or 
maximum time, can be reached by using linear programming 


techniques. 


2 





Constraints wnich can be applied to the linear pro- 


Tulor > 


gramming problem are: S mate. ‘ 


6 a 
Z ff Ct @ bg: 


Peepeeeed source lines of code Ss = Ck ne as Z 


d 
f Lys 


maximum peak manpower K/t, < ve y' (max) 
minimum peak manpower re < ve y' (min) 
eee ie. K 
Deecimum ditraiculty gradient + ™< VD ae 
d= ‘a 
lV’ / : ; j 
Ci c fy] 
delivery time ta < contract delivery time 


budget $/MY(.4K) 


[A 


total amt. budgeted 
for development 


with the objective function being the software equation and 


beth * and te being the decision variables. 


ee [ee yl/3 ee 


Continuing with the previous example, the constraints 


aee . 


| VD| 14.7 (Stand-alone system) 


3S 600.000 


Management nas realised the error of their ways and has 


establisned a three year development time and an$8 million 


es 


{ 


J 





mii wepm@ent Sudget. It has also been determined that a 
minimum of thirty people and a maximum of eighty people will 


De available at peak manning. Further constraints are: 


maximum manpower available < 80 people 
minimum manpower available > 30 people 
maximum time < 3 years 
maximum budget < $8M 


in order to fit the linear programming model, the con- 
straints and objective function must be linearized. By 
applying logarithms, the objective function and constraints 
become: 
Spbgeetive function: 
minimize 


meommcian< + 4/3 logec, = log Ss = log Ck 


d 


Sapyeet to: Log 


Mmeemreeek 2 4/3 log t, < 300000 - log 10946 


d £05. 


1/3 log K + 4/3 log t, >*300000 - log 10946 


d 
log K - 3 log ere log 14.7 
meee - 3 log os Mog Ta 
log K - log t, < log (Je 80) 
lope - log t, > log (Ye 30) 
log eG < log 3 
log K < log ((8000000/500000) ¢.4)) 
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Graphically applying the objective function and the 
constraints results in Frigure 18. Because the constraint on 
the number of source lines of code is graphically parallel 
to the objective function, there will be an infinite number 
of solutions with the minimum time/maximum cost and maximum 
time/minimum cost solutions bounding a feasible region along 
eee source lines of code constraint. In this particular 
example, ta Jteoe line Ene solution and aftect the following 


optimal solutions: 


t, (years) K (MY) ECMY) SE 
min time 27 Sone BOA 2 S65 0575722 
Min cost 3.00 254.2 Oi a Soe dled. Zen 


The manpower constraints do not, in this instance, effect 
the solution, but altering the manpower constraints could 
Sesubeein a totally different optimal solution. 

A tradeoff region lies between t, = 2.82 years/K = 327.8 MY 


d 


and om aay kK = 2otee MY On Ghevobjective function. 


<q 
Clearly, by altering any of the constraints, new optimal 
pemetetons Can nesult. Yet, given the constraints of this 
particular example, the solution is more sensitive to develop- 


ment time as the difficulty gradient imposes the upper bound 


and cannot be changed. 


75 








Mn 
CU TTT ETT] 


aNUITITt OTT LILLE TU 
Ms 


ms 


fea. 














































































































































HATS ae HUET MEL TH PEELE ° 
FATT Ce AES HATER EEEEE EE 
AANA TIRE LE UPSTATE TTT © 
Ha CTT LST ; SUT Ey 
eT a AEE 2 
ll ose ENE eae 
he | 
| ce 7 cn i 
A ie 
a 
i a | 
y 
| 
| : | | Ee! 








1000 
on @ 
400 
300 
200 
160 


Grapnical Linear Programming Solution 
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Peowmees OF ILES 


tJ 


Beewrere—-cycle curve is not a single line, but a line 
With a Dandwidth about it (Figure 9). All the variables of 
the software equation are subject to some degree of uncer- 
tainty and the project manager must have a means of taking 
fis Into account in an effort to develop risk profiles. 

Already, a degree of uncertainty has been established 


for the difficulty gradient in Chapter III [Ref. 24: 154] and 


Tor source lines of code. Allowing for a standard deviation 


rH 


of fifteen percent of the base value of the difficulty 
gradient, |7D| = 14.7, and for oSs = 5985, as per the previous 
example, the following equations can be solved similtaneously 


pout the mean, and within ojVD| and oSs: 


mn 


ell 3. Pee a SS 
“q GOR 
K es 
—— = |VD| 
a 


(Ref. 20: 59] 


By solving these equations several thousand times on a 


a aA 


Bemputer, x, Ta? oK, and ot, can be determined. 
Management has decided to work toward the minimum cost 


Boe 1ution 


ee 





ct 


3 years 


a 

X = 254.18 man-years 
= = 101.67 man-years 
eee = $5,083,261 


and, arter performing a simulation, arrives at the following 


values: 
ee = 3 years 
hace Sa .25 years 
XK = 252.0 man-years 
OK = 20.4 man-years 


Risk profiles can now be graphically established for both 
SewelOpment time and effort using normal probability graph 
paper. 

Using the hypothetical example, to establish a risk pro- 
file for development time, the expected value, 36 months 
(three years), is plotted at the fifty percent probability 
level (Figure 19). Below this plot, at the sixteen percent 
probability level, one standard deviation, 3 months, is 
marked off. Because the scale of the paper straightens out 
the normal probability integral, only these two points are 
required to clot the graph. (Ref. 22: 34] 

The risk profile for development time shows a ninety 
percent confidence interval between 32.2 months and 37.8 


months. The project manager can be assured that there is a 
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J3 Dercent certainty that the project will not exceed forty- 
three months, barring external interruptions to the existing 
development environment. 

Likewise, a risk profile can be determined for life-cycle 
peers, K, (Figure 20) and given an average burdened cost, 
this can be easily converted to a life-cycle cost risk profile. 
Also, risk profiles can be developed for development effort 


and development cost. 


rr} 


s SUMMARY 
The economics of software can be expressed through the 


mathematical relationship known as the software equation: 


The software equation 1S a very powerful managment tool 
which mathematically reflects important economic and be- 
nhavioral characteristics to all those concerned with the 
software project. 

The software equation reflects the time sensitivity of 
the development process. Time cannot be changed without 
Chameing effort. 

zach software project has an associated minimum develop- 
ment time. Completed development cannot be expected to 
occur prior to this minimum time. Knowing the minimum develop- 
ment time and its uncertainty gives the project manager a 
framework from which to plan and control the software 
development process. 
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The trade-off law is an extremely powerful tool which 
offers the project manager the opportunity to save money by 
allowing more time for the development process, changing the 
development environment, and eliminating the "whistles and 


beais” from the project. 


SZ 





V. SLIM: AN AUTOMATED APPROACH 


A methodology whitch permits the project manager to 
answer the four management questions 

is the project feasible? 

What are the resource requirements? 

mere lLones will it take? 

What are the risks? 
has now Deen mathematically shown. Applying the techniques 
Dy hand is, at best, a tedious and time consuming chore. 
The process has been automated by Quantitative Software 
Management, Inc., and is available through American Manage- 
ment Systems, Inc. The Department of Defense has taken an 
interest in this particular methodology and has contracted 
the services of this automated software estimation package 
as well as an instructional package as per Government 
Contract MDA903-81-D-0062 (Appendix B). 

This chapter will be devoted to the SLIM (Software Life 
Cycle Model) package, what it does, its weaknesses, and what 
Precan do for the project manager. 

Gee sea versatile, highly flexible software system 
that is designed to help software managers and analysts 
estimate the cost, manpower, and time to build" software 
systems. [Ref. 25: 1-1] All outputs are in terms of usable 


management parameters. 
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SLIM automates three functions (Table 5). The Estimate 
Function has various options (Table 6) which allow the user 
to design the system development process, update an ongoing 


SevYelopment process, and validate vendor proposals. 


me 3 6owilM EXAMPLE 

Peojem@s the easiest method to fully explain SLIM is to 
demonstrate the power and flexibility of the system through 
an example. 

1. Scenario 

The software project 'Thesis Example' is a rebuild, 

business application, system. The project has just entered 
the functional design phase. The project manager, in order 
to update development plans, wishes to use SLIM given the 
Bol lowane constraints: 

Development time: 42 months 

Development begins: January 1983 

Maximum budgeted cost: $5.5M 
| Maximum number of men available at peak manning: 60 

Minimum number of men available at peak manning: 30 

Average burdened labor rate ($/MY): $50,000 

@@sc Of Capital: 10% 

ieee t=1On, the following is known about the system 

development environment: 

Percentage of on-line development: 100% 


begeentage Of the Se eee computer dedicated 
to the development effort: 80% 
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Table 5 


SLIM Bumetivons 


Peet O Obtain his comical data trom ene User . 
This data will be translated internally into a 
"State of Technology" factor for the user's 
organization. It is then used to calibrate the 
model to the way a particular organization 
typically develops software. 


Allows the user to interactively create a data 
File describing a new software system. 


Is used to obtain cost, schedule, and manpower 
estimates once a data file has been built. 


ies wseage tO Gmdene "ellnrene: session. 
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LINEAR PROGRAM 


NEW TIME 


ees iG tO COST 


Pent SIZING 


TRADE-OFF ANALYSIS 


Table 6 


SLIM Options 


This function uses the technique of 
linear programming to determine the 
minimum effort (and cost) or the 
minimum time in which a system can 
be built. The results are based on 
the actual manpower, cost, and 
schedule constraints of the user, 
combined with the system constraints 
described earlier to yield a con- 
Serained  OpLima.) soumtlton, 


SLIM will automatically determine the 
minimum time schedule for which 
development of your system is feasible. 
This function may be used to set an 
alternative schedule for development. 
A new corresponding cost will be 
provided. 


Ties TUmeeETom ts used to allow the 
user to set a new level of effort and 
cost for development. A new time 
schedule will be generated. 


This technique is used to generate 
the best estimate of total source 
statements and the associated stan- 
dard. deviation. 


This 18 a very powerful technique 
which allows the user to compare the 
costs and manpower necessary to build 
a system over various time scheudles. 
This analysis demonstrates the extreme 
time sensitivity of developing soft- 
ware - as time decreases, the costs 

go up dramatically. Also, a minimum 
Feasible time schedule is shown, indi- 
cating that for the size and type of 
system is shown, indicating that for 
the size and type of system described, 
a shorter time schedule simply cannot 
be imposed upon it. 


86 





maps 5 continued- 


PPONT=END ESTIMATES 


MAN LOADING 


CASHFLOW 


meow ANALYSIS 


Smee t LT ANALYSIS 


MEbooLONaS 


This function provides low, average, 
and high estimates of the time and 
effort required for the feasibility 
study and functional design. 


This function is based on a monte 
carlo simulation of total manpower 
and time. Projections of the mean 
number of people (and the standard 
deviation) on a month-to-month basis 
are provided. These projections are 
based on an optimal application of 
resources throughout development. 


This function is based on a Monte 
Carlo simulation of manpower, time, 
S/MY, and inflation rate to provide 
projections of the expected cashflow 
on a month-to-month basis throughout 
development. 


This function provides a table of 
expected manpower and cashflow over 
time throughout the operations and 
maintenance phase. 


This function determines the proba- 
bility of developing a system within 

a specified time or for a specified 
cost. It is very useful for strategic 
planning purposes, by providing the 
risk associated with various time & 
cost decisions. 


This function computes the benefit of 
your system in $/year required to 
amortize the cost of development and 
maintenance. It is based on the 
anticipated economic life of the 
system as well as the average rate of 
return for your organization. 


Based on a predetermined total develop- 
ment time, this funetion provides a 
realistic schedule for the major 
milestones of the project. 
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Beale 6 cOontinued- 


CPU USAGE 


DOCUMENTATION 


ALL ANALYSES 


EMD 


This function provides a table of 
expected machine usage over the life 
cycle of the system, along with an 
estimate of total machine hours 
required for development. 


Based on the total system size and 
data from hundreds of similar soft- 
ware systems, a range of expected 
pages of documentation is given. 


This function calls all of the above 
Functions automatically except 

“new time* and “design to cost*. If 
a complete analysis of a system is 
desired, it 1S recommended that you 
use *new time* or *design to cost* 
to set your desired schedule, and 
then call “all analyses* for a com- 
plete analysis. 


This command may be used to return 
Gtomene SLEies cnem Mons tor. 
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Pemecntacse Of system coded in a high order 
language (HOL): 100% 


mem usec: COBOL 


Percentage of the target machine's memory 
utilized by the system: 50% 


Percentage oI real-time code: 0.0% 
Tecnnology rfactor that has been calibrated: 9 
in addition, modern programming practices will be used 
extensively except that there will be no chief programmer 
teams. The project personnel are very experienced in terms 


skill and familiarity with COBOL; however, they have only 


Ft) 


Oo 
an average experience with the development computer and with 
PaeovSseem Of this Size. 

The technology factor was derived using the Calibrate 
function and historical data. The difference between the 
technology factor and the technology constant will be dis- 
cussed later in this chapter. 


oes Application 


Given the previous information, the project manager 


Can call on the Editor function to build a file for the 


Broject. 





EVI TOF 


SSH SPSS SSH OS HP SSHSHHS HHP PH SHS SHOSE OPS HSOHP SH SSS SSH SHPO EHD GH HHH SHH DOP SSF SCHHSHOH OCHO 


Dee sont ige SLLGh. TRE UWlee TO ENTEPACTIVELY TET We A NEM DATA FILE 
BETLPISiNG A CCFTWREE TEVELQFMENT TYITEM. ‘VOU WILL BE FREOMPTED FOF ALL 
INFORMATION. THE FELONIES VOU FePOVItE WILL EE WlED TO DETERMINE: 


eee TYPE HD NIFRICULTY GF ‘OUF = eTEMs 


(ey) URE Serie OF TECHHGLOe: BEING APFLIED TO DEVELOPMENT: AND 

(32) COSTIne INFORMATION AEGUT TOUR OFGANIZATION. 
REL IMPORMNATION "ILL EE SeY'eD GNM FILE FOR LATEP URFDATES OF ACCESS. 
SOtTriyT FIlLEMANE THE oT. 
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ft should be noted that a technology factor, vice a 
Becnnology constant, 1S required for SLIM. By using two 
Mmum@ide@e: sequences (0,1,1,2,3,5,8... and 0,2,2,4%,6,10...), 
technology constants are internally assigned a technology 
factor. [Ref. 24: 153] In this example, the technology 
Beetcer Or 9 equates to a technology constant of 5168. 

oLIM offers a very powerful tool for firms lacking 
the historical data necessary to calibrate. A default value 
or 0 for the tecnnology factor signals SLIM to select a 
technology factor. This is accomplished by taking the mean 
technology factor of the Rome Air Development Center and 
adjusting it in accordance with the answers supplied while 
Meme £ne Editor function. 

MWovwmunat @aetile is built for Thesis Example, the 
Droject manager would want to use the Estimate function to 


make pertinent cost, manpower, and time estimates. 
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Output is based on PERT sizing and the software 
equation. The standard deviations are extremely important. 
Not only do the standard deviations indicate a range about 
the expectea value, but they also offer a device for testing 
peeeem Sensitivity. All simulations are run by generating 
random variables within the given standard deviations and 
making use of Monte Carlo simulation techniques. 

It should be noted that the consistency check indi- 
cates abnormalities within the project that will have to be 
considered. This consistency check is done against the data 
Dase of the Rome Air Development Center. 

Given a minimum development time of 31.2 months with 
a development effort of 2211.4 man-months, the staffing of the 
development effort, the time of the major milestones, the 
front-end estimate, and a risk analysis should be examined. 

The front-end estimates are based on historical data 
of system size versus feasibility study time and effort, and 
system size versus functional design time and effort. Data 
Weed for this option comes from IBM-San Jose. The project's 
development curve is determined and SLIM, in effect, extra- 
polates backwards to derive the front-end time and manpower 
requirements. Using system size to estimate the awenteoena 


certainiy an unscientific method, hence the large uncer- 


}- 
UY) 


tainty bounds. Yet, there is no other feasible means of 
estimating the front-end of a project but through historical 


data. Given the uncertainty bounds, this method is quite 
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Beweeosectory. Front-end estimation is an important option 
and is one the project manager would be wise to use; the 


Front-end can incur roughly fifteen to twenty percent of 


fmne lite-cyche cost. 
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Xnowing that this project definitely cannot exceed 
42 months, the project manager can use the Design-to-Risk 
Sption to determine what his maximum development time should 
be in order to assure a 39 percent chance of not exceeding 
feemenens. If this time is greater than the 31.2 minimum 
time, the project manager has an opportunity to improve his 


OSation by decreasing effort and cost. If the resulting 


me 


time is less than the minimum time, he can again use this 
epreeon, but with smaller risk options, in an effort to 


meeresse effort and cost. 
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It should be noted that given a project duration of 
Pomc Mentis, the consistency check now shows the project 
within the normal range of the Rome Air Development Center. 

Now knowing that he can plan on a development time of 
So.¢ MONLAS with a 99 percent chance of not exceeding the 42 
month limit, the project manager can run the Linear Program- 
ming option to determine the time/effort/cost data for a 


minimum cost solution and a minimum time solution. 
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Having updated the file for Thesis Example, the 
project manager can now use the Estimate function to deter- 
mine the managerial information he requires to plan and 


@emerOl the project. 
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SLIM is not intended for one-time use. It can serve 
the project manager throughout the life of the project. As 
estimates become more refined or as requirements change, the 
tile can be updated and SLIM estimates can serve to aid in 


mee UpGecing of plans and in the comtrol of the project. 


B. CONTRACTING APPLICATION 

SLIM can be extremely useful in evaluating vendor pro- 
posals itor software contracts. By requesting the development 
efrort, development time, and system size of past projects, 
as weli as the estimated new project size in PERT format, 
in the Request for Proposal (RFP), each vendor can be cali- 
Deeated amd the propesals evaluated for validity. 

If the user also determines system size, even when using 
a default technology factor of 0 (zero), a best time/effort/ 
cost estimation can be made from which the vendors can be 
again be evaluated. 

As the number of clients of the SLIM estimating package 
grows (Table 7), the ability to even further validate vendor 
proposals also grows. Knowing that a vendor used SLIM to 
determine his time/effort/cost estimates, the project manager 
can now verify the proposal uSing the vendor's SLIM inputs to 
dete»*magne the proposal'’s validity. 

SLIM can do mucn toward eliminating cost and schedule 


overruns. Not oniy can it assist in project development and 
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i. 
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nS 


14. 


HES 


abo... 


ans. 


eo 


Pepi, 


Dele eitents as or 2O5dune 1991 


American Management Systems, Arlington, Virginia 
Blue Cross/Blue Shield of Illinois, Chicago, Illinois 
Boeing Computer Services, Inc., Seattle, Washington 


Burroughs Corporation, World Headquarters, Detroit, 
Michigan 


Perasousns Comporaction, Program Products Division, 
Radnor, Pennsylvania 


Perougns COonpoOration, Program Products Division, 
Atlanta, Georgia 


Burroughs Corporation, Program Products Division, 
Miami, Florida 


Burroughs Corporation, Program Products Division, 
Pevrme. California 


Bpuerouchis Corporation, Program Products Division, 
Charlotte, North Carolina 


Central Intelligence Agency, Washington, D.C. 

Computer Management, Incec., Atlanta, Georgia 

Dynamics Research Corporation, Wilmington, MA 

Federal Aviation Administration, Washington, D.C. 
Honeywell Federal Systems Operations, McLean, Virginia 


Honeywell Large Information Systems Division, Phoenix, 
Arizona 


Honeywell Process Management Division, Phoenix, Arizona 
I3BM Federal Systems Division, Manassas, Virginia 


IBM Federal Systems Division, Westlake Village, 
California 


I3M Federal Systems Division, Gaithersburg, Maryland 





Teble 7 continuted- 


20. 
ma 


a 


eS. 


Mees, Lted., London, United Kingdom 
Planning Research Corporation, McLean, Virginia 


United States Department of Defense (includes Army, 
Navy, Air Force, Marine Corps, and all Defense Agencies) 


Vought Corporation, Dallas, Texas 


Source: Quantative Software Management, Inc. 
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control, but also by allowing the user to easily determine 


which vendors are submitting valid proposals. 


Sect heRiA FOR THE GOODNESS OF A SOFTWARE COST MODEL 

Some method of evaluating SLIM is necessary to determine 
its erfectiveness as a software costing model. Barry W. Boehm 
and Ray W. Wolverton, of TRW Defense and Space Systems Group, 
have proposed nine measures of goodness as a basis on which 
to compare a software cost model. [Ref. 4: 129] 
im Wer inition 

The model must clearly define which costs it is estimating 
ema @aten Costs it is not. 
i Tidela ty 

The estimates that are generated by the model must be 
close to actual expended costs. 
& Obpectivity 
The model must not allow for subjective factors that can 
Sway the model in any desired direction. 
Pe Constructiveness 

The user must be able to understand why the model gives 
<he estimate it does. Also, the model must help the user 
understand the software job. 
5. Detail 

The model must be able to easily subdivide a project 


imto phases and activities. 


ASG 





| SeebaiLty 

The model must reflect appropriately sized output per 
unit of input. No mathematical surprises can be generated 
by the model. 
i Scope 

eiemuoeci must cover the class of software project to 
be estimated. 
3. Ease of Use 

@he model's inputs, outputs, and options must be easy 
to understand and specify. 
9. Prospectiveness 

Tne model must not depend on information that is not 
well known until the end of the project. It must be able to 


meeeetetom 1m a Useful manner with the information at hand. 


DBD. EVALUATING SLIM AGAINST THE CRITERIA 

Boehm and Wolverton suggest that this criteria is impor- 
tant in determining the utility of a software estimating 
mecel. Using this criteria, the utility of SLIM can be 
assessed. 
i Deiinition 

SLIM clearly defines what it is estimating: size, time, 
effort, cost, risk, trade-offs, manpower, cashflow, code 
production, documentation, development computer time, and 


the front-end of the project. 
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Be. Fale l ity 

SLIM has been validated against over four hundred pro- 
jects from the Rome Air Development Center and others. 
me «6«Obaectivity 

It is extremely difficult to sway SLIM because of the 
G@aca COnStraints inherent to the problem as well as those 
management constraints serving to define the software pro- 
ject's environment. Resultant times less than the minimum 
possible time are not allowed. 
4. Constructiveness 

SLIM 1s completely consistent with the underlying theory. 
Ba addition, it offers the user an insight into why con- 
straints are either reasonable or unreasonable. The most 
important aspect in understanding the software development 
effort is the identification of minimum time; SLIM immediately 
identifies minimum time. 
9. Detail 
The front-end of the project is estimated in terms of 
time, effort, and manpower. System development is estimated 
in terms of time, effort, manpower, code production rate, 
risk, and budget. The Operations and Maintenance phase is 
estimated in terms of manpower, budget, cost and, risk. 
Activities are not estimated. Activities are based on spe- 


cific organization methodology and is within the domain of 


the project manager, not SLIM. 
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Sop Lary 
All output 1s consistent with the exponential and quantum 
Ggemaeteriscics of the model. 
[= scope 

SLIM is applicable for all classes of software systems 
involving a group problem solving effort. SLIM is based on 
the human intercommunication within the software process. 
8. Ease of Use 

SLIM inputs and outputs are extremely easy to understand. 
As system design becomes more refined, input ranges become 
ere eand OULDUtS become more accurate. Output is in 
terms of usable management parameters. 
Ss mrospectiveness 

SLIM is completely consistent with the amount and 
availability of information. Based on input characteristics, 


SLIM's output informs the user of the degree of accuracy. 


SP SSEDIOWEAKNESSES 

Although it nas been shown to be a very valuable manage- 
ment tool, SLIM does display several weaknesses. 

There is a tremendous range of values for the difficulty 
gradient, |7D|, between the rebuild and composite II systems. 
Although increased uncertainty compensates for this range, 


further classification of systems within this range of 


difficulty would further enhance program accuracy. 
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SLIM can be inconsistent with current Department of 
DetTense life-cycle methodology. SLIM output assumes project 
Continuity. The sequence of events leading to DEOgieCe 
@be Oval prior to each life-cycle milestone can lead to 
Peaks 1m the project schedule. This inconsistency, if 
anticipated by the project manager, must be taken into con- 


sideration when planning the software project. 


vJ 


EF. SUMMARY 

SLIM offers the project manager an extremely powerful 
tool ror managing tne software development process in terms 
Oe Stanning, budgeting and control. Sizing through the PERT 
Sizing technique, simulation via the Monte Carlo technique, 
linear programming, and sensitivity analysis through risk 
profiles provide an accurate time/effort/cost analysis. 
SLiM's accuracy has been validated for over four hundred 
Systems spanning the entire range of system types: from 
operating systems, real-time, and scientific applications to 
the most mundane business application. SLIM can be used 
throughout the entire planning and development phases of the 
pee ject in order to facilitate planning and control. Project 
data is easily updated so that SLIM can be an effective tool 


wnen requirements or constraints change. 


Applying SLIM to Barry W. Boehm and Ray W. Wolverton's 


(2) 


riteria for the goodness of a software cost model shows 


SLIM to be an extremely viable software estimation model. 
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SLIM does display a few minor weaknesses. More system 
types need to be identified in the difficulty range between 
Beeetia and composite Il systems. SLIM output can be incon- 
Sistent with current Department of Defense life-cycle 
methodology. These weaknesses are minor and certainly do 
Hetedtseract from the effectiveness of SLIM as a powerful 
tool for the software project manager (Table 8). 

An extremely important facet of SLIM is that it takes 
into account the transition zone, as discussed in Chapter 
TII. It is an effective tool for small, medium and large 
projects. If any two of the following four attributes apply 
memene  >rOoject, SLIM can be used: 

Ss 1s greater than or equal to 5000 

Peak manpower is greater than or equal to 3 people 

Development time is greater than or equal to 6 months 


Cost is greater than or equal to $100,000. 
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Table 8 


Putnam's Version of the Characteristics 
- 


of a Good Software Cost Estimating System 


Should have a sound phenomenological basis that relates 
to other Similar, known processes and which contributes 
to understanding the software system development process. 
smOuld apply to all organizations and classes of software. 


Can be adapted to any organizational structure and way 
of doing business. 


ES GOmesistent with existing, known data over the entire 
Slze range. 


Can be easily calibrated or "tuned" to a specific 
Omganazation. 


Accepts management constraints on time, cost, manpower. 
Should have "what 1f" capability to specify alternative 
cost, schedule, manpower and risk conditions within 
constraint bounds. 

peeduees bounded solution sets. 

Produces accuracy bounds on all answers. 


Permits risk evaluation and risk specification. 


Should produce consistent manpower and budget implemen- 
tation plans for each time-cost-effort solution. 


Should be capable of adapting to anticipated changes in 
environment, technology, language, skill, complexity and 
modern programming practices. 


input information is easy to estimate. 


Gives a measurable achievement projection (rate of code 
production). 


Produces a projection of life cycle time, effort, man- 


power and budget together with accuracy bounds on these 
quantities. 
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Taere 8 continued- 


16. Is capable of adaption to future (new) environments. 
Makes extrapolation into such new environments straight 
Berward and relatively safe. 


17. Allows partitioning into major system phases. 
18. Permits separate analysis of modules. Aggregation of 
these pleces should show when and how much "overhead 


work" (management, integration, test & validation, 
Gocumentation) has to be done. 


reproduced this with permission of L.H. Putnam, 
Quantitative Software Management, Inc. 
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Vo 7 CONGEUSTONS 


Planning and controlling the software development process 
has shown, in the past, to be an extremely difficult task. 
The estimation or resource requirements, development costs, 
risk profiles and project feasibility has often proven to be 
MefecUrate, thus costing the user both time and dollars. How- 
every, by using obtainable management parameters, and simple 
eng*neering and operations research techniques, estimating 
can be done easily and accurately by taking a macro approach 
<o the estimation problem. 

The methodology discussed in the study, as developed by 
Lawrence o. Putnam, is based on the empirical findings of 
the reiationship between the software life-cycle and the 
Rayleizh curve, mathematically expressed as 


Z 
yl = @kate ~ 


The Rayleigh equaticn can be used to determine project man- 
loading, cumulative manpower, and cash flows. 


A powerful software economics tool, the software equation, 


Ss = ck x’’* +,"/? 


cifers the opportunity to trade-off manpower, development 
time, and the development environment in order to obtain an 
Optimal development solution in terms of minimum cost or 

ml nan time . 
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The automated software estimation package, SLIM, makes 
Meer Or tiese two equations, as well as engineering and 
Operations research techniques, to form an extremely power- 
ful tool for the project manager. 

SLIM and its underlying mathematical basis reflect intui- 
tive observations of the software development process: 

Each software system has its own minimum development time 

Large projects take more effort 

Complex projects require more effort and time 

Improving software development tools and techniques 

results in an improved development environment which, 


in turn, effects development in a positive manner 


A gradual growth in manpower is the most efficient 
manloading pattern 


SLIM is based on the nistorical data of past development 


projects which allows it to be calibrated to the development 


history of the user. In addition, it can function as a ‘what 
if' analysis tool so that the user can design the software 
@eveNOpment project based on cost, schedule, or risk. SLIM, 


being completely consistent with the criteria set forth by 
Barry W. Boehm and Ray W. Wolverton, offers the project 
manager of any software project a viable software estimation 
model. 

SLIM does, however, reflect several weaknesses: the 
necessity of identifying further system types in the diffi- 
culty range between the rebuild and composite II systems, 


and the possible inconsistency with current Department of 
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Defense life-cycle methodology. As previously stated, these 
weaknesses do not distract from the effectiveness of SLIM 
as 2 powerrul tool for the software project manager. 

By using SLIM, the project manager is able to accurately 
answer the four management questions in terms of costs and 


resources: 

Is the project feasible? 

What are the resource requirements? 

How long will it take? 

What are the risks? 
Being able to answer these questions, the project manager 
can now prevent the mistakes of past projects and accurately 


Piemeancd Control the software project. 
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APPENDIX A 


Variables That Correlate Significantly 


With 


Question or Variable 


Customer interface 
complexity 


User participation 
mene derinition of 
requirements 


Customer originated 


Programming Productivity 
[Ref. 28: 6u, 65] 


program design changes 297 


Customer experience 
with the application 
area of the project 


Overall personnel 
experience and 
qualifications 


rercentage of pro- 


grammers doing devel- 153 
opment who participated 
in design of functional 


specifications 


Previcus experience 
were Operational 
computer 


Previous experience 
with programming 


Previous experience 
Ween application of 
Similar or greater 
size and complexity 


Ratio of average 
staff size to dura- 
tion(people/month) 


Response Group ProaneEry? by 
Mean Productivity Change 
(DSL/MM) COS Mi 
Normal Normal >Normal 
500 Ze 124 376 
None some ue a 
u91 267 203 286 
rew Many 
196 oa: 
None Some Much 
318 340 206 ez 
Low Average High 
ee Zs 410 278 
<25% 25-50% >50% 
242 Seek 238 
Magma). Average Extensive 
146 270 gat 166 
Minimal Average Extensive 
E22 2S 385 263 
Minimal Average Extensive 
L146 Zoom 410 264 
<0%S 0.5-0.9 >0.9 
S05 3) 110. es aw 





Hardware under concur- No 


rent development 


PeeeLOpment computer 
access, open under 


Development computer 
access, closed 


Gieassitred Security 
environment for 
computer and 25% of 
programs and data 


Smeuctured 
programming 


Design and code 
inspections 


Top down development 


Chief programmer team 


usage 


Overall complexity 
of code develoved 


Complexity of appli- 
cation processing 


Cempiexity of 
program 


Overall constraints 
on program design 


Program design con- 
Straints on main 
storage 


Program design con- 
straints on timing 


Code for real-time 


or interactive opera- 


tion, or executing 
under severe timing 
constraint 


Za 


0-33% 
iio 


0-33% 
220 


0-33% 
136 


0-33% 
ZA 


siverace 
314 


<Average 
345 


<Average 
289 


Minimal 
Zoe 


Minimal 
391 
Minimal 


303 


<10% 
279 


1-25% 
274 


11-85% 
Powe 


34-66% 
34-66% 
S00 


34-66% 
2o7 


34-66% 


Average 
345 


Average 
Zo 


Average 
286 


Pera gse 
208 
poveradge 


Say 


10-40% 
Sa 


eZ 


Yes 
Lie 


>25% 
oo 


>85% 
lev 


Yes 
TST. 


>66% 
301 


>66% 
oo 


>66% 
SZ 


>66% 
4O8 


>-Average 
eG 


>Average 
168 


>Average 
eu 


Severe 
166 


Severe 
193 


severe 
toy 


>40% 
203 


P20 


ea 


one 


ee 


139 


ie 


80 


ey) 


is 


oe 


76 





Percentage of code 0-90% 


for delivery 159 
Bode Glassified as 0-33% 
non-mathematical ap- 188 


olication and I/O for- 
matting programs 


Number of classes of 0-15 
mtems in the data base 334 
per 1000 lines of code 


Number of pages of 0-32 
delivered documenta- 320 
tion per 1000 lines of 
delivered code 


91-99% 
ae 


33-66% 
Saek 


16-80 
243 


33-88 
ZZ 


Low 


100% 
209 


>66% 
Zo) 


>80 
193 


>88 
io 


106 


79 
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APPENDIX 3B 
Department of Defense Memorandum 
Concernincs sLiM 

The following memorandum serves to focus Department of 
Defense interest in SLIM, notify automated data processing 
users of its implications as a tentative standard Department 
oz Derense methodology, and to notify users of the contracted 
training sessions conducted by Quantative Software Management, 


Mme. 
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VPriCle OF IME ASSISIANT SECRETARY OF DEFENSE 


WASHINGTON OC 20301 


8 MAY ‘odi 





mmPTROLILER 


MEMORANDUM FOR ADP POLICY COMMITTEE (PROGRAM MANAGEMENT) 


SUBJECT: Contract Support for Standard Software 
Development Estimates 


We have been working together for some time to improve the 
Department's capability for estimating software development 
resource requirements. In 1976 a DoD working group selected 
a two part methodology. This approach has been under test 
at a large number of DoD software development centers since 
ono 


Recently, the first part of the tentative standard 

DoD methodology entered the commercial market as an 

automated model accessible through commercial timesharing. 

I nave become sufficiently impressed with the ease of use and 
the ready response to "what if" analysis, in the commerical 
version, to obtain funding for a DoD-wide license for this 
product. It is my hope that this will expedite widespread 
use of this capability. 

Under the contract which we have negotiated, OSD has paid the 
annual license fee for DoD-wide use and for four one week 
training sessions which we plan to hold at DODCI. Any 
organization in DoD wnich wishes to use the capability will 
write a delivery order against our contract and will pay for 
usage; training for a limited number of persons will be free 
(except for TDY costs if necessary). Additional details are 
attached. 


It has been demonstrated to my satisfaction that we can save 
large amounts of money if: 


- We do not try to do the impossible, i.e., develop 
software in less than the minimum time required. 


- We make informed decisions about reducing gold 
Dlating, i.e., focus software development on the minimum 
essential requirements. 


- We optimize the application of manpower, i.e., a 
Small stretch-out in schedule planned at the outset may 
substantially reduce overall cost. 


- We monitor valid thresholds for deviation from plan, 
1.@., Know wnat reasonable deviations from plan are. 
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Bt Yeast one person at any activity which plans to use SLIM 
should be trained in the use of the model prior to making any 
extensive use. The first training session has been filled. 
We are taking nominations for future sessions. If you wish 
tO nominate people to receive training, please provide my 
orfice with the name, organization and telephone number of 
those persons wishing to attend the 10-14 August session by 
30 June. Similar information should be provided by 14 August 
for the two remaining sessions which have been scheduled for 
the October-November 1981 and February-March 1982 timeframes. 
Specific dates on these sessions will be provided later. 


Your assistance in giving this information the broadest 
cossible distribution would be appreciated. My points of 
contact for this effort are Mr. Robert Cooper, 695-2554, 

phe 225-2554) and Ms. Scarlett Curry, 697-8632 (AV 227-8632). 


ee 
a ae eae ya : 
btg PY, (abate te 


a John M Carabello 
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GENCRAL CONTRACT INFORMATION 


the contract has been issued by: 


Defense Supply Service - Washington 
noom iD2453, The Pentagon 
Stanincwons B.C. 20310 

mieten: SSrs. Katie E. Moulder 
AUTOVON 227-6021 


Commercial 202 697-6021 
Mne  CGmebeact Number is: MDASO3-81-D-006? 


Me@ewconeraecr 15 for the acquisition of an annual lease and 
miecense fee [or unrestricted use of a proprietary software 
Dackage, Sortware Life Cycle Management Model (SLIM) for all 
DoD organizations; and for access to the model thru tele- 
@eocessing services, also provided for under the contract. 
The sOttware license fee has been paid by the Office of the 
Secretary of Defense. LIM is resident on the American 
Management Services, Inc., computer systems. Teleprocessing 
services to access SLIM will be ordered via call orders to 
tae @onitract. 


Complete copies of the contract and additional information 
may be obtained from the Contracting Officer's Technical 
Representative: 


Rob Cooper 

Assistant Director Data Automation 
OASD(C) MS DDA Fm 1A658 Pentagon 
Woon eeonen D.C. 20301 


meOUISITION APPROVAL 


The Office of the Secretary of Defense has approved the 
acquisition of this capability for software development 
organizations, organizations that monitor contract software 
development, and audit or cost estimating organizations. 


A delegation of procurement authority has been obtained 
which covers all DoD activities of the type described above. 
A "2068" has been processed thru GSA to obtain Sharing 
Program approval. Any further action of this type will be 
taken by the COTR if it appears necessary as a result of 
unexpected growth in DoD wide usage of the contract. 


By virtue of the actions described above, potential users 
Witnh2n DoD have the authority to issue call orders through 
bie Cwm acquisition activity for use of SLIM, subject to 
Tecate fund availability. 





Ge orders which exceed $10,000 should be coordinated 
eeiepnonically with the COTR prior to issuance to facilitate 
planning. 


ORDERING INFORMATION 


Orders may be issued under this contract from 1 May 1981 
meu 30 Aprali 1982. Information concerning renewal of the 
contract will be furnished at a later date. 


Orders should be issued thru properly executed DD Form 1155 
and mailed to: 


American Management Systems, Inc. 
1777 Kent Street 
Arlington, VA 22209 


Two coples of each call order will be sent to the COTR. An 
installation Representative (IR) will be designated by each 
ordering activity. The ordering activity should provide 
Defense Supply Service Washington with the name, mailing 
address, and telephone number of the IR. The name and 
address of the IR will also be cited in the call order* so 
that invoices may be forwarded to the IR for certification 
of receipt of services. The call order shall site the 
SQ@gn1zZant paying Office. IR's will certify and approve 
invoices for payment and forward them to the paying office. 


*=Block 14 DD Form 1155 
PRICING INFORMATION SUMMARY 


(These are GSA/TSP prices. Reference should be made to the 
contract for more detailed information) 


Remote Terminal Connect Charges 


Prime Hours Non-Prime 
Washington, DC Metro Area $7.00/hr $4.00/hr 
eZee 1d 
Outside Washington, DC | 7 .00/ ar $4.00/hr 
Upton l 200 Daud Plus communications charge 
Communications Charges $7.00/hr Sl Olena 
WEEN ET 
CPU Utilization Charges* $.14/RUS* Seo ko 


Peco. S0an=20 


ote we 
du aw 


50% surcharge will be added to the CPU costs. 
= Resource Unit 


AY b> 


U 
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File Storage Charges 1-1000 pages S .64/page/mo 
(Permanent) 1001-2000 pages $ .39/page/mo 
2001-4000 pages S$ .26/page/mo 

Over 4000 pages $ .18/page/mo 


PoUeMEANG CALL ORDER COSTS 


A rudimentary method for estimating the cost of using SLIM 
is to estimate the number of manhours available to operate 
the model, e.g., 2 people X half a day X two days per week 
equates to 16 hours per week, assuming the people don't work 
together on one terminal. Costs per hour can be expected to 
range between $15 and $75 per hour. The variance between 
these amounts relate to the sophistication of the users and 
the amount of detailed printing of schedules, etc. Costs at 
the high end may indicate that a greater benefit is being 
obtained. 


TRAINING INFORMATION 
Instructor: “Mr. Lawrence Putnam 
Teaining Vendor*: 


Quantitative Software Management (QSM) 
1057 Waverly Way 

MeLean, Virginia 22107 

(703) 790-0050 


Stee) ceainine vendor will certify attendance and course 
Pemeletiom For administration purposes not for billing - 
@EEPIning Organizations are not billed, as the courses have 
been prepaid by OSD 


boeation of Training Site: 


Dobe eompuicer Institute 
Be@aiding 175 

Washington Navy Yard 
Waehington, D.C. 20374 


Length of Course: Five (5) days 
Paes omeoet.  furtion —- paid by OSD, no cost to trainees’ 
organization 
TDY - paid by trainees' organization as 
required 


esi 





The following documentation shall be furnished to each 
trainee: 


SLIM Users Guide 

AMShare Users Guide 

Tuteriai Test, "Software Cost Estimating and Life Cycle 
Control: Getting the Software Numbers," IEEE Cat No 
EHO 165-1 

peecicu, oseiM = Sample Output 


Folder, QSM, Schematic Diagram of Software Life Cycle 
Methodology 


Student workbook containing exercises and examples in 
use of SLIM and AMShare 
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